Background and Relevant Art
Computers and computing systems have affected nearly every aspect of modern living. Computers are generally involved in work, recreation, healthcare, transportation, entertainment, household management, etc.
Further, computing system functionality can be enhanced by a computing systems ability to be interconnected to other computing systems via network connections. Network connections may include, but are not limited to, connections via wired or wireless Ethernet, cellular connections, or even computer to computer connections through serial, parallel, USB, or other connections. The connections allow a computing system to access services at other computing systems and to quickly and efficiently receive application data from other computing system.
Interconnection of computing systems has facilitated distributed computing systems, such as so-called “cloud” computing systems. In this description, “cloud computing” may be systems or resources for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services, etc.) that can be provisioned and released with reduced management effort or service provider interaction. A cloud model can be composed of various characteristics (e.g., on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, etc), service models (e.g., Software as a Service (“SaaS”), Platform as a Service (“PaaS”), Infrastructure as a Service (“IaaS”), and deployment models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.).
Cloud and remote based service applications are prevalent. Such applications are hosted on public and private remote systems such as clouds and usually offer a set of web based services for communicating back and forth with clients.
To achieve the goal of predictable performance for all customers of a cloud server, mechanisms are used to control the amount of resources that each cloud customer can use. Without such mechanisms, starvation (unfairness) can occur since computing resources like CPU cycles are provided to all customers in a free-for-all manner. In some cloud environments, customers will be able to subscribe to specific Service-Level-Objectives (SLOs) that provide exclusive reservations on resources like CPU cores and worker threads. To simplify these products, there are only a small number of SLO “sizes” that customers can choose from.
For example, a “small” SLO provides ½ a CPU core, “medium” provides 1 CPU core, “large” provides 2 CPU cores, “xlarge” provides 4 CPU cores, and “xxlarge” reserves the entire server (logically 8 cores—although other processes exist and also use cores). Additional resources such as worker threads, memory, and disk IOs can be reserved in proportion to the CPU core SLO definitions. Going from any SLO size up to the next higher size will double the number of worker threads).
An xxlarge SLO customer occupies an entire server (continuing the running example above). As each SLO resource reservation is scaled in multiples of each other, embodiments can guarantee that a homogeneous placement of the same SLO size in a server will fill the server perfectly.
However, when there is heterogeneous placement of SLOs on a server, embodiments may end up with “holes” in the server that correspond to unallocated resources on the server that can't be used to “fit” a specific new tenant. For example, if a server has a “small” tenant and a new xxlarge tenant arrives that requires the entire server, then this new tenant can't be placed on the current server. This situation may be repeated, in different ways, with other tenants and servers in the cluster. The result is underutilization and poor cost of goods and services as embodiments may end up needing to provision more servers than necessary.
Furthermore, accommodating elasticity and dynamicity in cloud environments, such as SQL Azure™ may require that embodiments intentionally leave resource space for new customers and/or changes in the SLO size of existing tenants (e.g., an existing tenant upgrading from small to a medium SLO size).
The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technology area where some embodiments described herein may be practiced.